
The Assembly Language Journal of Merlin Programmers 



VoM No 12 January 1989 








Belay that last issue, matey. 

Last month I told you all about my determination to 
move The Apprentice into the "next level" in the 
publishing hierarchy. What I didn't tell you is that 
I've been negotiating like a maniac for weeks trying 
to launch a new publication - which would consume 
The Apprentice and replace Call A.P.P.L.E, 

Allow me to explain. 

I think we all agree that the Apple II programming 
community desires a multi-language technical 
journal. Call A.P.P.L.E. filled that niche nicely for 
years. I do like nibble for some things, but a true 
technical journal does not publish RoidBlaster and 
the like. It strives to propogate detailed program- 
ming knowledge and up to date information. I'm not 
really being critical of nibble, mind you - 1 don't think 
they make any claims towards technical jour- 
nalhood. 

That means, then, that Call A.P.P.L.E. 's death leaves 
a void - which I am determined to fill. I think we at 
the of Ariel cabin can do it, and do it well, so I'm 
going to lay it all on the line and see what you think. 

Enter 8/16 

The new publication will be called 8/ 1 6. Like its 
predecessor, S/J6willbe heavy on the source code. 
The following environments will be covered in 
monthly columns: Orca C, Micol Advanced Basic 
GS, Merlin 8 and 16 bit assembly, Applesoft, and 
ZBasic. All other environments will be represented 
as we get articles and code. At present, we have 
spoken to authors interested in writing about Pascal 
and APW/Orca assembly. The magazine looks like it 
will be 48 pages per month, about 1 5% of which will 
be devoted to advertising. We plan to keep the type 
size small, the listings single column wherever 
possible, the colors black and white, and the clip art 
minimal. I am inclined to call it a "no-nonesense" 
kind of programming journal. A one-year subscrip- 
tion will be $29.95. 

Unlike Call A.P.P.L.E., 8/ 16 will publish a monthly 
companion diskette (available for $69.95 for one 
year, $39.95 for six months, and $21 for three 
months) . The disks will have approximately 300K of 
8 bit and 300K of 16 bit code, articles, product 
demos, public domain software, and just about 
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anything else you could imagine. All of the article 
text and source code for the current issue of 8/ 16 
will be in there, as well as a few additional articles 
and tutorials that are not in the hardcopy version. 

We shall fulfill existing Apprentice subscriptions 
(and Reboot and Znews) on an issue-for-issue and 
disk-for-disk basis. I think this is a good deal 
because you'll be "trading up", gettting a 48 page 
publication in place of a 12 pager. As a proud Merlin 
supporter, I assure you that Merlin assembly list- 
ings will always have a prominent place in the new 
journal. My goal is to provide you with what you have 
been getting and then throw in a whole lot more , too. 

The key to making it all happen is going to be 
attracting advertisers. By combining our three 
Apple II publications, we have a built-in subscriber 
base right from the start. I have already created and 
sent out advertising kits to over 30 Apple II hardware 
and software companies. If you know of any one who 
expresses the slightest bit of interest in advertising 
in 8/ 16, please drop me their name and address - I'll 
ship 'em a kit ASAP. 

I am very excited about 8/16, and I'd like to thank 
Jack Nissel, Wally Matusak, Roger Wagner, Mike 
Westerfield, Jay Jennings, and Eric Mueller for their 
encouragement and support. You folks helped bring 
this to pass. 

Speaking of Eric Mueller... 

Eric Mueller, a frequent contributor to The Appren- 
tice, hasjoined our staff as an Associate Editor. He'll 
be in charge of the GS sections of 8/ 16, both in the 
magazine and on the disk. 

As a favor to me while we "retool" for the new 
publication, Eric is producing this month's issue of 
The Sourceror's Apprentice. 

For your information, Jerry 'The Ampersand King" 
Kindall (currently the editor of Reboot) is going to be 
the editor of the 8 bit sections of 8/ 1 6. 

NOTE: Missing a Month 

The first issue of 8/ 1 6 will hit the newsstands and 
your mailboxes on March 1st, 1990. To make this 
happen, there will be NO February issue of The 
Apprentice. If you have not received the third and 
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fourth SApp quarterly disks (for those who ordered 
it), please drop us a note or give us a call. We want 
to have our books up to date and accurate by the 
time we make The Transition. 

I've not come out and said it yet, but this is obviously 
the very last issue of The Sourceror's Apprentice, I 
am glad that, for once, the disappearance of an 
Apple II publication is not the final act of a financial 



tragedy. Still, it is the end of an era, albeit a short 
one. I hope that you end up feeling that your support 
of us this year has been rewarded by the greater 
range and depth of the new 8/ 1 6. 

Certainly, only time will tell, but I pledge our best 
efforts. 

== Ross == 



From the Generic Mohawk Department: 

Trapping Tricky Tool Errors 

By Jay Jennings 

We've seen more than enough Generic Startup routines to last for quite a while. In order to continue our 
"Generic" articles, I had to come up with a routine that's useful and... generic. This error trapping routine 
is used in all my programs. In fact, it's stuck right in my generic startup source code file so I never forget 
about it. 



Most error trapping routines that check for toolbox errors send your program straight to the bottomless pit. 
They're usually called with a piece of code like this: 



ldx 
jsr 



8$1111 

Check4Error 



; our error ID number 



And the routine itself looks like this: 



Check4Error bcs 
rts 



: error 



; error 



pha 

stx :ErrCode 

"Hexlt :ErrCode 

Pu 1 1 Long : ErrCode 

"SysFailMgr « : Deathtlessage 



; if carry set we got an error 
; otherw i se get outta here 

:save the toolbox error code 
:save our error ID number 
; change it to a hex number 
:get and save the result 
: display our death text 



DeathNessage dfb 
startMessage asc 
ErrCode ds 



asc 



® : endflessage- : startMessage 

'fit $' 

4 

1 ; Error $ ' 



;endMessage 



Now, there's nothing wrong with this method, but when you're developing a program, you're liable to crash 
your program more often than not. And rebooting every 10 seconds after crashing into Sliding Apple Hell 
gets to be a major hassle. With the help of Lane Roath and Eric Mueller, the Generic Error Trapper has evolved 
into a k-rad subroutine that's very useful and handy. 

There are two major changes in the error routine. Instead of using an error ID number to show where our 
program died, we can use a complete string of characters. And instead of calling SysFailDeath, you get the 
chance to continue with the program or to jump straight to your shutdown routine. This way, you can 
continue if you know the error that just occurred isn't necessarily fatal, and if you do decide to quit, you won't 
have to reboot the machine. 
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By using a macro we can call the error routine like this: 

"NewHandl e ® 1024; Prog ID; ®$8000; 80 
CheckError ' NewHandl e call in INIT.S file' 

The error code itself is pretty straightforward. We use an AlertWindow to allow the program to continue 
execution, or branch to our ShutDown routine. And we take advantage of the substitution string capabilities 
of AlertWindow to print our error string and toolbox error code. (Check your back issues of SApp for more 
information on using this powerful feature of AlertWindow.) 

First of all, let's look at the macro that makes this nifty routine so quick and easy to use. 

get low address 

get high address 

do that error check th i ng 

if uue came back, no error 

our error string text 

end of text mark [C string) 

end of the macro 

This macro is very simple. It grabs the address of our error string and puts it in the X and Y registers. Then, 
we call the actual error trapping routine. If there was no error in the last tool call, we'll come right back and 
branch around the error string that's in our code. However, if there was an error, the address of the error 
string will be used to print it in our AlertWindow. 

Here's the code for our new and improved error checking routine. 



CheckError 


mac 






ldx 


«string ; 




ldy 


® A str i ng ; 




jsr 


Check4Error ; 




bra 


]here ; 


str i ng 


asc 


]1 ; 




dfb 


00 ; 


]here 


eom 





Check4Error ent 
bcs 



: error 



;rts 



rts 



; error 



stx 

sty 

sta 

"Hexlt 

Pul lLong 

"fll ertW i ndouu 

pla 

beq : rts 

jmp ShutDown 

rts 



SHR1 
SHR1+2 
ErrCode 
ErrCode 
ErrCode 
«0; ® : Array; « : Text 



; if there was an error, branch 
; otherwise, get outta here 

;new code Cbelow) will be added HERE 
;save the low word of the address 
;save the high word of the address 
,save the tool error 
; change code to a hex number 



,-grab the result of AlertWindow call 
;if (Continue), me should continue 
; otherwise, shutdown NOW! 



:Text asc 
asc 
Array adrl 
SHRladrl -1 
ErrCode asc 



'62 | Fatal 
'Cont i nue| 
: ErrCode 

1 ,00 



error *0: *1 . Vou should shut down.| 
"Shut Down 1 ,00 



; four spaces 



There you go... a generic toolbox error checking routine. Unfortunately, this only works for desktop based 
programs. Fortunately, adding some code to make it work as well under the text environment is relatively 
easy. 



By adding the following code you'll have an error checking routine that prints an error message on the text 
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screen or the SHR screen. 

Since there's no way I know of to tell whether the SHR screen is active or not, we can do a bit of juggling and 
get a routine that should work in most cases. To the beginning of the error routine (right after the : error 
label), we add some code to see if the Window Manager has been started, like this: 



:DoSHR 



phx 

phy 

pha 

"Wi ndStatus 

pi a 

bne :DoSHR 

brl DoText 

JBrafOn 
pi a 
ply 
plx 



;save address to error string 

;save the error code 

;see if the Window tlgr . is up 

;if WM is started, use fllertUindow 
otherwise, use text stuff 

;make sure SHR screen is turned on 
; restore our registers 



If the Window Manager is active, we can be pretty sure that the tools we need for the AlertWindow are started 
up as well, and we can go on with the routine as normal. The call to Graf On is there just in case the program 
was switched into text mode when the error happened. There are not many programs that switch from one 
mode to the other, but several of mine do, so it's better to be safe than sorry. 

If the Window Manager is not active, we'll use a modified version of TLTextMountVol ume to put the message 
on the screen. It's modified only to the extent that the message we use doesn't say to put in a specific disk 
(which is what it's normally used for). Here's the code that will place our error message and toolbox error 
code on the text screen: 



DoText 



] loop 



:QotIt 



_GrafOff 
pi a 

piy 

plx 
stx 
sty 
sta 



sep 
ldy 
Ida 
beq 
sta 
iny 

cpy 

bne 

sty 
rep 

"Hexlt 
Pul lLong 



50 
52 
:TErrCode+2 

«$30 

[50] , y 
:GotIt 
:Textl+l,y 

836 
] loop 

:Textl 
«$30 

:TErrCode+2 
:TErrCode+2 



;make sure text screen is showing 
; restore our registers 



;save our error number 

; go down to <gulp!> 8-bits 

get a character 
;if zero, we're at the end 
save i t for our use 

have we done 36 chars yet? 
if not, keep looping 

save the length byte 
back to 16-bit everything 

; change code to a hex number 



"TLTextMountVol 8 : Textl. 

pi a 

cmp «2 

beq ■. rts 

jmp ShutDown 



« : TErrCode; 8 : Qu i tBttn; 8 : ContBttn 
;see what button they chose 
;2 = ESC, 1 = CR 

;go to our shutdown routine 
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:rts 


rts 




: Textl 


ds 


40 


: TErrCode 


str 


'$ 


:ContBttn 


str 


'Continue <ESC> 


:QuitBttn 


str 


'ShutDouin <CR>' 



; space for the error string 
; do liar sign 8. four spaces 



Notice that, since fll ertW i ndow uses C strings (NULL terminated) and TLTextllountVol ume uses Pascal 
strings (with a leading length byte), we have to transfer the error message into a Pascal string. There is 
another way around this, as fll ertU i ndoui will also deal with Pascal strings if you tell it to do so. Since all 
my other A 1 ertW i ndow calls use C strings, I decided to remain consistent and juggle the string a little if the 
text version of the error window is required. 

Also, the maximum length of the error string is 36 characters in the text version. This is because 
TLTexttlountVo 1 ume switches to a 40 column screen (for some unknown reason!) to display it's message. 

There are a couple of potential problems with this routine as written. Since we turn on or off the SHR screen 
(depending on what mode we need for display purposes), you may not be in the correct mode if you decide 
to continue instead of shutting down. So far that hasn't actually been a problem for me, but I can see where 
you might want to modify the code so this couldn't happen. 



From the Mailbaa 'o Fan Department: 
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By Mike Rochip 



Hi Mike... 

I finally got a chance last night to sit down and read 
the November/ December issue ofSApp. I wanted to 
congratulate you on the sliglxtly different format... I 
think that the "modular" programming stuff will be 
very useful. 

I did want to point out a couple of descrepancies in 
this issue, though: 

1 . In the Demo Module, you declare your externals 
this way: 

EXT Imprtnt,errorlist,MIl_Error 

Since I use Merlin 16,1 won't have any problems, but 
Merlin 8 users must put each external on a separate 
line. You might want to make a note of it for new 
users. ..they may become confused when they can't 
get it to work. 

2. In the article itself you say "Try to not to get excited 
when the demo tells you your volume bitmap may be 
damaged". Well, you won't have to worry about that 
happening... the demo can never cycle through Mil 
error $58. In line 49 of the demo, and in line 34 of the 



MLI error handler, you load X with a #28. There are, 
however, 30 errors in the table. It should have been 
loaded with a #29. Since the error message for the 
"volume bitmap damage" is in upper /lower case, and 
the other are in all caps, it appears that you might' ve 
added the "volume bitmap damage" message at the 
last minute, and forgot to increment the X register to 
allow for it. 

3. Also, because of the demo module itself, you will 
never see error $l.To see error $ 1 , the X offset would 
need to be loaded with "0". In line 62 (of the demo 
module), you only branch on a BNE. 

As soon as the X register hits "0", the program will 
end, instead of doing the $1 error msg. Change the 
BNE to a BPL, and it will work. . . the branch won't take 
place until X becomes $FF on the next loop. 

Sorry to cause so much trouble from my first read- 
through of SApp, but I thought that you'd want to 
know. I'm not trying to be picky... I think that SApp is 
a GREAT programming magazine, and I LOVE IT! 
Keep up the good work! 

Tom Hoover 
Lorena, Texas 
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Dear Mike: 

Eric Soldan's article in the September issue is fine, 
but I think there is a bug in the source code, on page 
five. As published, the beginning ofPDLADD reads: 

PDLflDD pip ; restore interrupts 

adc ®0 ; add value of carry 

Since we cleared the carry before saving the interrupt 
status (with a clc, php several lines up), the adc #0 
line does exactly nothing. I think the light code for this 



section must be: 



PDLflDD 



adc ®0 
pip 



; add value of carry 
; restores interrupts 
and clears carry 



Nobody is perfect! 

Sincerely, 

Yvan Koenig 
France 



From the Parentheses and Brackets Department: 
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By Steve Stephenson 



One of the prices we pay as assembly language programmers is the responsibility of managing memory. (I 
believe that high level languages were intended for those who would not accept this responsibility. . . but I'm 
not here to pursue that discussion today.) 

In my last letter, I extolled the virtues of using a mini-direct-page in the stack and the Direct Page Indirect 
Long Indexed address mode (LDA [0],Y). Well, as most of you know (or should know), that addressing mode 
may only be used when you are sure that the block of memory you're addressing is all on the same bank. 
"When you ask the Memory Manager for a block of memory to use, the attributes must include 'attrNoCross' 
($xxlx) to guarantee that the block is completely contained in the same 64k bank. 

But what do you do when you'd like a block larger than 64k? Or simply want to ease the demands on the 
Memory Manager and make more efficient use of all the odd scraps of memory? Well, for openers, you don't 
set 'attrNoCross' when you ask for the block. You also must use a different addressing mode! Or, as sure 
as bugs, when you least expect it, the Memory Manager will grant you a block that straddles two banks! The 
Direct Page Indirect Long Indexed addressing mode wraps around back to address $0000 on the lower bank 
instead of continuing into the higher bank (very much like the JMP ($20FF) bug in the 6502). This creates 
a bug of the worst order: the kind that doesn't always appear, and is practically impossible to duplicate. 

So what addressing mode can you use for these situations? Well, you can always use the Absolute Long 
Indexed mode (LDA >$2000,X or LDAL $2000 ,X). But that only works if you know ahead of time where the 
block of memory is — which is not good style for a desktop program on the Ilgs. The addressing modes that 
most nearly match the Direct Page Indirect Long Indexed while allowing for bank crossing are the Direct Page 
Indirect Indexed (that's the good old LDA ($0),Y we've been using foryears) and the really scary looking Stack 
Relative Indirect Indexed (LDA ( 1 ,S) ,Y) . 

Actually, both of these alternatives are nearly identical. They both add the value of Y to the base address, 
which means they can reach a full 64k. They both form the base address from a two byte pointer that is 
located inbankzero. More importantly, they both transparently increment into the next bank when required. 
It's just what's inside the parentheses that's different; one uses a pointer in the direct page and the other 
uses a pointer in the stack. 

There's a big catch to using these modes to reach anywhere in memory, though: you have to reset the Data 
Bank Register. And restore it afterward. It gets a little messy when you realize that your program is on one 
bank and the memory block is (most likely) on another bank. But I haven't found a better way to access a 
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runtime-assigned block that could cross bank boundaries. 

Some code fragments may help at this point. For this example, we'll assume that we are trying to put some 
known variable stuff (mystuff & morestuff) from our own code area into a block of memory that could be 
anywhere. Getting the new handle, locking it, and dereferencing the handle have already been done. The 
address of the block (myblock) is stored in your code space. And we are in full native (mx %00) mode. 



* the Direct Page style. 

Ida myblock+2 

xba 

pha 

plb 

plb 

1 dx myblock 

stx zptr 

Ida >mystuff 

sta (zptr] „ y 

iny 

iny 

Ida >morestuff 

sta (zptr] ,y 



;get the block's bank 

;f 1 ip it around 

put it on the stack (A is 16 bits] 
but PLB pulls only 8 bits; throw it away (zero] 
now Data Bank = memory block bank 

put block's address into direct page 
must use long addr . to reach 'back' to our code bank 
else it would try to read 'mystuff from this bank! 



phk 
plb 



; reset Data Bank back to our code bank 



* the Stack Relative style... 



Ida myblock+2 

xba 

pha 

plb 

plb 



;get the block's bank 

;f 1 ip it around 

;put all 16 bits on stack 

;pop first 8 bits and throw away (zero] 

;now Data Bank = memory block bank 



1 dx myblock 

phx 

Ida >mystuff 

sta (l,s],y 

iny 

i ny 

Ida >morestuff 

sta (l,s) , y 

plx 



;put block's address on top of stack 

; must use long addressing to go back to code bank 



:fix the stack (pop the block's address] 



phk 
plb 



and reset Data Bank back to our code bank 



These methods may be harder to follow, but if you need to float your block of memory anywhere, then 
they may be your only answer. The stack relative method may be the only method if you have no direct 
page. 

The biggest problem I've had using these methods is forgetting to use long addressing when the data 
bank is temporarily reset. 

So, if your memory is all on the same bank, feel free to use the new square brackets. . . but if it isn't, 
then you need to be using good old parentheses. 
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By Ross Lambert and Eric Mueller 

At the heart of almost any application using the 
popular desktop metaphor is a screen pick rou- 
tine (also known a screen snatcher). This useful 
(and powerful) chunk of code is designed to 
quickly save a piece of the screen and later, put it 
back up in the display memory. (For example, it's 
the key to the menu manager's menu caching.) 

This month, we're presenting a double hi-res 
screen snatch routine: with it, you can pass top, 
left, bottom, and right coordinates, and the 
routine will lift your data right off the screen into 
a buffer. At that point, you can destroy the screen 
(within the rectangle you just saved, of course). To 
fix the screen back up, it's simply a matter of 
telling the snatch routine where your data was 
stored, and that you want it to be put back on the 
screen. 

In order to cut down on code size and make it 
more applicable to desktop applications, the 
program's coordinate system mirrors the 80 
column screen — the smallest piece of data that 
the snatch routine can work with is exactly the 
size of one 80 column screen character, seven 
pixels wide by eight pixels tall. If you're working 
with a double hi-res character generator, this 
screen snatcher is perfect! In order to keep within 
screen bounds, the largest X coordinate you may 
pass is 79 and the largest Y coordinate you may 
pass is 23. 

Because of the usefulness of this routine, it was 
decided to make the program completely relocat- 
able. As a result, it can be loaded anywhere in 
memory and may be used from Applesoft, ZBA- 
SIC, and just about any other language you can 
call it from. 

Let's dive right into the code. Once we're past the 
header information and miscellaneous assembler 
pseudo-ops (lines 1-22), we start with the 
equates. Most are clearly commented, but let me 
mention a few important ones: line 26, "data", 
must be filled In before you call this routine. It's a 
two byte pointer to the buffer where you wish the 
screen data to be stored. In order to determine 
how many bytes to reserve for the buffer, use this 
formula: data_buffer_size = ((right - left) * 8) * 
(bottom - top), or, put differently, data_buffer_size 
= (horiz_width * 8) * vertjieight. 

Lines 35-38 are the X and Y coordinates for the 
top left corner and the bottom right corner of the 
rectangle you wish to save. Remember, set these 



coordinates as if you were dealing with the 80 
column screen... 0-79 for the horizontal axis and 
0-23 for the vertical axis. 

Finally, line 39, "direction", is a very important 
flag: it controls whether or not you want to move 
data from the screen to the buffer (save the image) 
or from the buffer to the screen (restore the 
image). Poke a zero for the former and a one for 
the latter. 

The program starts at line 53 by locking out 
interrupts, calling a known RTS in the monitor 
ROM, allowing interrupts to begin again, and then 
leaping over the lookup table. This lookup table 
(lines 58-81) is used to determine the base ad- 
dress for each of the 24 vertical positions we can 
address on the DHR screen. 

At "startl" (line 87), the program checks on the 
stack for the last return address, placed there by 
the JSR to the known RTS, above. Once we have 
the address, we store it in the zero page pointer 
PTR, and then, with PTR, self-modify the two 
location-dependent lines of code in the program: 
the instructions at labels "modify 1" (line 119) and 
"modify2" (line 122). 

Once we have those locations properly set, and a 
couple of miscellaneous variables initialized (lines 
112-113), we're ready to start moving the screen 
data about! "Yloop" (line 115) is the outer loop for 
the entire program. It starts by locating the base 
address for the line (0-23) that we're going to 
store/restore from. The inner loop, "Xloop" (line 
126), begins next. 

After setting the pointer "BASE" to the correct 
base address, the program determines if it should 
work with main or auxiliary memory and set the 
softswitches and an internal flag ("aux_flag") 
appropriately (lines 125-135). At the label "main", 
the program adds the horizontal offset to the base 
address in order to get a pointer to the actual 
character cell we're interested in saving. 

Here, at lines 147-148, the program branches 
depending on what you wish to do: if you want to 
store data into your buffer, we continue on 
through to the label "byteloop" at line 153. How- 
ever, if you chose to restore data to the screen 
from your buffer, the program branches to the 
label "restore" at line 202. Let's take a look at 
"byteloop" first. 

Once determining what page we're working with 
(main or auxiliary) and flipping the appropriate 
Softswitch, we loop through the storage of one 
byte, at lines 158-167: get a byte from the screen, 
flip to main memory, get the offset into the data 
buffer, put the data byte away, and bump the 
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offset forward. If we're not done with the entire 
eight-byte-tall single character block (the check is 
at line 169), then we continue to loop through 
"byteloop". 

When we are finished storing that character cell, 
the routine starting at line 181 ("Xck") takes over. 
It first checks to see if we're done with this row 
(horizontally), and if not, branches back to 
"Xloop". If we are finished with that row, we fall to 
"Yck" (line 188) to see if we're done with all of the 
rows (vertically). If not, the code returns to "Yloop" 



for the next row down. Otherwise, it falls through 
to "exit" and return to the calling routine. 

The "restore" code (starting at line 202) is exactly 
the same as the store code, except that the proc- 
ess is reversed. In other words, from lines 202- 
219, we get the offset into the buffer, get a byte of 
the data, set the appropriate softswitches depend- 
ing on the screen column, and then drop the byte 
onto the screen. Once an entire screen cell is 
completed, the routine finishes (line 222) by going 
back up to "Xck". 



1 

2 

3 

4 

5 

6 

7 

8 

3 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 

21 

22 

23 

24 

25 

26 

27 

28 

23 

30 

31 

32 

33 

34 

35 

36 

37 

38 

33 

40 

41 

42 

43 

44 

45 

46 

47 

48 

43 

50 

51 

52 

53 

54 



1st off 

Hi H< Hi Hi Hi Hi * Hi Hi Hi Hi Hi* Hi H< Hofc* Hi Hi Hi Hi Hi Hi Hi Hi Hi Hi Hi Hi Hi Hi Hi Hi Hi 



DHR Screen Snatch 
by Ross W. Lambert 
Copyright CCD 1388 
fill Rights Reserved 

vers ion 2. Is (w i th 
January 13, 1330 



'Eric M0dz'D 



* 
* 
* 

* 

# 
h< 



>t< Hi Hi Hi Hi Hi M* Hi Hi* Hi Hi* Hi Hi Hi Hi Hi Hi Hi Hi Hi * H< Hi H< Hi Hi H< Hi Hi Hi >$<>&<>*< 



orgfiddr 



xc 

mx 

dsk 

exp 



org 



111 

dhr .save 

off 



orgflddr 



* zero page & stack 
BASE = $06 

data = 
PTR 



STfiCK 

* Page 3 freespace 
st_offset = 
oldbase = 
aux_flag = 

xtop = 

ytop = 

xbot = 

ybot = 

direction = 

* ROM 

return = 
STOR80off = 
STOR80on 
STOR80rd 

PflQE2off 

PRGE2on 

PRGE2rd 



$0fl 
$100 



$0300 
$0301 
$0303 
$0304 
$0305 
$0306 
$0307 
$0308 



$FF58 
$C000 
$C001 
$C018 

$C054 
$C055 
$C01C 



Hi Hi Hi Hi Hi Hi H<Hi H< Hi Hi Hi H< H<HiHi H< Hi Hi Hi Hi Hi Hi Hi Hi Hi Hi Hi Hi Hi Hi Hi 



; allow 65c02 opcodes 
;eight bit everything 

: don't expand macros 

;put this code here 
; Cit is relocatable - 



change to anything] 



;our zero page pointer 

;FILL IN: pointer to screen data storage 

; current position of this program's data 

: address of stack 



;data offset storage 

;old base address for each screen byte 

;auxilliary memory flag 



;FILL 
;FILL 
;FILL 
;FILL 
;FILL 



x coord of top left 

y coord of top 1 eft 

x coord of bottom right 

y coord of botom right 

0=save screen/l=restore screen 



start 



SEI 
JSR 



return 



; harmless RTS in ROM 

; Softswitch to make PflQE2on point to main mem p2 
; Softswitch to make PfiQE2on point to aux.mem pi 
; reads status of 80STORE toggle switch 

.•selects page 1 main mem always 

; selects pi aux mem if STOR80on selected 

; reads status of PRQE2 switch 



;lock out interrupts 

:goto harmless RTS to leave our LOC-1 on stack 
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55 
56 
57 
58 
59 
60 
61 

63 

64 

65 

66 

67 

68 

69 

70 

71 

72 

73 

74 

75 

76 

77 

78 

79 

80 

81 

82 

83 

84 

85 

86 

87 

88 

89 

90 

91 

92 

93 

94 

95 

96 

97 

98 

99 

100 

101 

102 

103 

104 

105 

106 

107 

108 

109 

110 

111 

112 

113 

114 

115 

116 

117 

118 

119 

120 

121 

122 



CLI 

BRR 

DW 
DW 
DW 
DW 
DW 
DW 
DW 
DW 
DW 
DW 
DW 
DW 
DW 
DW 
DW 
DW 
DW 
DW 
DW 
DW 
DW 
DW 
DW 
DW 



start 1 

@$2000 
#$2080 
«$2100 
•$2180 
•$2200 
•$2280 
«$2300 
•$2380 
*t$2028 
®$20R8 
®$2128 
®$21R8 
«$2228 
«$22R8 
*$2328 
*$23A8 
*$2050 
8$20D0 
*»$2150 
«$21D0 
*$2250 
«$22D0 
»$2350 
•$23D0 



;jump over table 



ne 





ne 


1 


ne 


2 


ne 


3 


ne 


4 


ne 


5 


ne 


6 


ne 


7 


ne 


8 


ne 


9 


ne 


10 


ne 


11 


ne 


12 


ne 


13 


ne 


14 


ne 


15 


ne 


16 


ne 


17 


ne 


18 


ne 


19 


ne 


20 


ne 


21 


ne 


22 


ne 


23 



DHR LOOKUP TABLE 



H< >H >U >{< H* H< >* H< H* »}< >$< H< H< >{< >H * * * H( H< & >$( >i< )fc H< H< >l< >{< >l< >$< H< M< H< H< H< >*< >t* H< >t< >)< >*< H< H< H< >S* H< H< >{< >{< **< H< >*< H< H< * *!< * **>(<>*<>(<>*<>$<>$<>!< 

* f i gure out where the heck we are and store on zero page 

* * >fc H( * H< H< H< >fc >$< >J< >fc >H * * >j< >{< & tfr * >{( * ^ >4< >}< »f< >4< tb >^ )|< >$< >f< >fc >{< )|< »H >{4 >$< >|< >|< * >fc >(( >}< * >$< >$< & >fc >{< >fc *H<>6<>f< *>*<>{< >4<>fc>[<>t<H<>J<>i<H< 



startl 



Vloop 

modifyl 
modify2 



TSX 
DEX 
CLC 
LDR 
RDC 
STR 
I NX 
LDR 
RDC 
STR 

LDV 
LDR 
STR 
INY 
LDR 
STR 

LDY 
LDR 
STR 
INY 
LDR 
STR 

STZ 
LDR 

PHR 
RSL 
TAX 

LDR 
STR 
I NX 
LDR 
STR 



STACK, X 

85 

PTR 

STACK, X 

#0 

PTR+1 



;put stack pointer into X 

,get low byte of our current position 

;get high byte 
;and store it 



TS v, 

C L C 

flt>C 

St a 
!»/ 

6 ° 



t&T^&W-^ 



IP T ?■■ 



.1 o,)U 



«modifyl-orgfiddr-7 ;modify location of screen lookup table 
PTR 
0>TR],Y 



PTR+1 
0>TR),Y 

»mod i f y2-orgAddr-7 
PTR 
0>TR],Y 

PTR+1 
(PTRD,Y 



p>, "-K 



JW 

Oi/j/' 



O&^a- 



Jj p fccJ-t-A? 



st_offset 
ytop 



screen, X 
oldbase 

screen, X 
oldbase+1 



; clear storage offset 

;get vertical position CYTOP] 

; store on stack 

; double it Clookup table in 2 byte pairs] 

;shift to use as offset 

;get lowbyte of base address from lookup table 
; store i t 

,now do highbyte of base address 



CZ7te Sourceror's Apprentice 



-L- %4st4& ~L -i- 



124 
125 
126 
12? 
128 
123 
130 
131 
132 
133 
134 
135 
136 
137 
138 
139 
140 
141 
142 
143 
144 
145 
146 
147 
148 
149 
150 
151 
152 
153 
154 
155 
156 
157 
158 
159 
160 
161 
162 
163 
164 
165 
166 
167 
168 
163 
170 
171 
172 
173 
174 
175 
176 
177 
178 
179 
180 
181 
182 
183 
184 
185 
186 
187 
188 
189 
190 
131 
132 



Xloop 



LDA 


xtop 


PHfl 




LDX 


oldbase 


STX 


BASE 


LDX 


oldbase+1 


STX 


BflSE+1 


STZ 


aux_f lag 


LSR 




BCS 


ma in 


STX 


aux_f lag 


CLC 




ADC 


BASE 


STR 


BASE 


LDfl 


BflSE+1 


ADC 


«$00 


STA 


BASE+1 


LDX 


87 


LDV 


80 


LDfl 


direction 


BNE 


restore 



; store current horizontal position on stack 
;get back old base address for this vert, line 
; store i t onto zero page 
;now do highbyte 



;cl ear flag 

;divide by two (due to divided nature of DHR screen] 

;cols 0,2,4,6, etc in aux mem/ 1,3,5 in main 

;set auxmem flag 

; add horizontal position/2 to base address 



: in it byte counter 
; and offset 

; snatch screen (03 or restore it (13? 



>fc # * >}< * H< H< M< * H< H< * tit >*< * * * * *}< * * H< H< H< H< >H * * * ** >*< H< H< H<>toj< >i<>&oloi< H< H* >{<»!< 

* reads in all 8 bytes in one screen block 



byte loop 



main2 



sa^/e os 



LDfl 
BEQ 
SEI 

STfl 

LDfl 
STA 
CLI 
LDV 
STfl 

INY 
BNE 
INC 
STY 
LDY 
CPX 
BEQ 



aux„f lag 
ma in2 

PRGE2on 

(BASED, Y 
PRGE2off 

st_offset 
(data] , Y 



save os 

data+1 

st_offset 

80 
80 

Xck 

f 



DEX , p i . 
C^CLC ) ^"^ ' " ? " ~ 
LDfl" BASE+1 
ADC 8$04 
STfl BASE+1 
BRA byteloop 



; are we i n auxmem? 
;0 means main memory 
;lock out interrupts 
;set Softswitch 

;get screen data from 1st byte in block 
;set Softswitch so we're back in main mem 

;get storage offset 
; store it 



;did it roll over to zero? 

; - if so, increment highbyte of data ( <>$FF ] 

; save new offset 

; clear y offset 

;all done with screen block 

;else decrement counter 

; add 1024 to get next byte in screen block 

ft £ C 



Xck 



Yck 



PLA 

cup 


xbot 


BCS 

INC 
BRA 


Yck 

<bC (L. 

Xloop 


PLA 




CMP 
BCS 


ybot 
exit 



INC 



;pull off current horizontal position 
; compare current hpos to ending hpos 
; if done, advance Y loop 

; increment horizontal position 



;get last vertical line done off stack 

; compare current vertpos to ending vertpos 

; if done, exit 

; ino vertical 1 ine 8 
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133 




BRfl 


Yloop 


;and branch back 


194 










195 


ex it 


RTS 






196 










197 










198 


^ >H K< * & >4t ^< >i< >fc * * H< >t< >H >H H* >fc >fc * >fc H< H< * >fc >l< & >fc H< »fc >fc >fc M< H< >l< >H M< * >fc ^ 


193 


* Restore 


indicated 


portion of 


screen 


200 


»{<>fcH<^H<>fc>$<>fcM<>fc>^>l<H<>fcM<>&M<H<>fcM<%>^M<>fc>l<H<>fcH<>fcH<>^>fcH<>fc>l<>fc>fc>fl<H<^>l<H<^^ 


201 










202 


restore 


LDV 


st_off set 


; get current data storage offset 


203 




LDR 


(data) , Y 


;get data 


204 




I NY 




; incrememt data offset 


205 




BNE 


:3 


; d i d it rol 1 over? 


206 




INC 


data + l 


;if so, increment highbyte 


207 


:3 


STY 


st_offset 


; save new offset 


208 










203 




LDY 


30 


;cl ear offset 


210 




PHFI 




; store data for awhile 


211 




LDR 


aux_f 1 ag 


; aux mem? 


212 




BEQ 


main3 


; if not, jump right to main 


213 




SEI 




;lock out interrupts when in aux mem 


214 




STR 


PRGE2on 




215 










216 


main3 


PLR 




;get back data 


217 




STR 


rj3RSE},Y 


; store byte to screen memory 


218 




STR 


PRQE2off 


;repoint us to main memory 


213 




CLI 






220 










221 




CPX 


#0 


jail done with screen block? 


222 




BEQ 


Xck 




223 




DEX 


\-' % ' 


; if not, dec counter and add next offset 


224 




CLC - 


.-. : ;— ) ■ ■■'"- l ft -^- 




225 




LDR 


BRSE+1 


;only need to add to highbyte 


226 




RDC 


«$04 


;add 1024 


227 




STR 


BRSE+1 


; can't ever wrap 


228 




BRfl 


restore 


r I c r 
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